One of the most important aspects of software development is program testing and verification. Testing involves determining whether software executes according to intended behavior. For example, Eiffel is a programming language with language constructs such as pre-conditions, post-conditions, or constraints (i.e., constraints). In one such example, a software developer writes constraints in source code such as a precondition before a method call, a post-condition after a method call, or other constraint elsewhere in the program. In such examples, the constraints are checked only at particular points in the program as dictated by their placement in the source code, such as before or after a call to the function. However, within the function or elsewhere in the program, the executing program can violate the constraints and make errors, and then only when the constraint statement is run does the error become evident. Additionally, every time this particular point in the program is encountered, the constraint is evaluated, even when variables associated with a constraint remain unchanged. Under these existing approaches, the constraint condition is verified every time the constraint is encountered in the program flow. Thus, constraints are only checked where indicated by the source programmer, and the constraint is always run at that point even when no state change has been made that might violate the constraint. Additionally, if a state or variable is changed elsewhere in the program where no constraint evaluation statement appears, then this constraint violation would go undetected. Thus, existing methods for checking constraints are both under-inclusive and over-inclusive.